Manage user access

Kustomer permission sets provide you with a way to customize what users and teams in your organization have access to and can see within the platform. Permission sets are fully customizable, allowing you to control what your users see based on your organization’s needs. For example, let’s say you are training agents and want to make sure that they can not mistakenly delete a customer, or respond to a customer support request while they familiarize themselves with the system. With permission sets, you can easily manage the access level for this group of users and either allow them to only have read/view access, or no access to certain actions at all.

With permission sets, you can also:

• Have the Ordering Department only see the custom objects that are relevant to them, such as the customer’s latest order.
• Allow an agent to create an order for a customer in their timeline.
• Prevent an agent from editing a specific attribute, such as a customer's email address.

Permission sets allow you to control the data, down to the object level, that your users see and determine what actions are available to them. For example, if you are a travel agency, you could define a KObject that stores booking information for each customer. With permission sets, you can prevent a user from performing actions on any of these objects, such as deleting a customer’s email address, or from even seeing the object at all. 

You can also apply permission sets to other areas of the platform, such as searches, reporting, and system settings. For more information, see Understand permission sets.

Permissions sets consist of individual permissions, or rules, that determine the level of access a user will receive. A user must be assigned a permission set or they will not have access to anything on the platform at all. 

Kustomer comes with five default permission sets: Owner, Administrator, Content Administrator, Manager, and User. These permission sets cannot be modified or deleted, but you can duplicate them and use them as a basis for a custom permission set by limiting specific actions or settings in them. 

When defining permission sets for objects, it is important to note that Company and Customer are considered top-level objects that control the default permission sets of lower-level objects. For example, if you assign a permission set to an agent that allows them to see the Customer object, you would want them to also see conversations with that customer, as well as pertinent information on the customer’s timeline, such as the order they are inquiring about. The default hierarchy on this top-level object will automatically allow this agent access to the Conversation object, as well as any defined custom objects. 

Related articles:

• Understand permission sets
• Use custom permission sets
• Best practices for permission sets